I suspect this borked some tests on SPARC.
http://nipy.bic.berkeley.edu/tgrid?category=pandas

can't figure out exactly which commit broke it, because buildbot hides history
and @yarikoptic isn't playing ball with ScatterCI :)

ok...i'll take a loook...these take forever to build...

I know. and now he's started submitting s390 bugs. lord help us.

all green! http://nipy.bic.berkeley.edu/tgrid?category=pandas

Nice. it really is an uphill struggle.

keep pushing on status ci

maybe you could even scrape it? (not ideal but might work)

What do you think I've been writing for the last 4 hours?

4 hours

thought u are a web guru :)

It's not structured. it's not even HTML. there are special cases.
I have to scrape the log without introducing bad data using monster regex's.
I have to add lots of logging, so I know what happened when data stopped updating.
I have to code defensively, do partsing errors to cause the script to die.
Then, I have to generate a valid xunit xml from the scraped data to submit to the server.
Then, I have to manufacture a fictitious env json description, because I don't
have access to the actual environment. So I have to research what debian sparc
reports when using python's platform module.
then, I have to update the UI to reflect different architectures on top of different OS.
then, I have to setup a cron job.
Then, I have to scrape all the builds retroactively.
Find bugs.
fix them
try again.

in short: don't be an *.

Sorry, I'm a little pissed off that I have to do all this work for no good reason.
And it's all, really, to save you some pain in supporting SPARC.

so. don't be an *.

just joshing you

don't take personally

didn't mean for u to do extra work

they should provide an easier interface if they expect us to support them

I'm not mad and people have genuinely more important things to take care of.
It's all good. Just about done anyway, check out the page in a few minutes.

@y-p whoosh that is awesome!!!

any idea of the build frequency....once a day or so?

The buildbot builds every 5 hours.
It seems it doesn't test only commits whose first parent is on master. For example
it may test a commit that's the 6th in merge that added 12.
So not only is it low-frequency, but many of those builds don't coincide with the
commits the rest of our CI boxes test. oh well.

Also seems different slaves test different commits according to when they become
available, randomly. So you don't get good coverage of a specific commit, more
like scattershot.

ok but will show red soon after something breaks so at least we know
I check your status page somewhat frequently so won't be suprised nearing the end of a release cycle
(like windows used 2 do)

The next step is email notifications, if there's demand for it. Would it be useful?

actually I think that would be quite useful

ideally message on a failure (just 1 per commit is enough)
then message when fixed

if that too tricky then just in a failure is ok

I would send to usual suspects

It'll be a CI mailing list, open to whomever is interested.

Probably within a few weeks.

gr8!